TL;DR:
All models are simplifications. That is not a flaw. That is the job.
A model that contains everything is not a model. It is just reality with worse graphics, more assumptions, and probably a steering committee.
The model below is a simplified stock-and-flow representation of a product delivery system. It shows how work enters a system, moves through stages, accumulates in queues, and eventually leaves as completed output. It is not trying to perfectly represent real life, because real life contains defects, rework, holidays, customer escalations, politics, legacy systems, budget cycles, procurement delays, and at least one spreadsheet called something like Final_FINAL_v7_ActuallyUseThisOne.xlsx.
The better question is not:
“Is this model completely accurate?”
The better question is:
“Is this model useful?”
In this case, the model is useful because it shows a central lesson from the Theory of Constraints: the performance of a system is governed by its constraint. Improving the wrong part of the system can increase work-in-progress, create larger queues, and make the overall system worse.
That matters for product managers because a roadmap is not just a list of things people want. It is demand entering a constrained system.
Why Models Matter
Human beings do not understand complex systems directly. We simplify them.
We draw diagrams. We create roadmaps. We make forecasts. We build spreadsheets. We create personas, process maps, architecture diagrams, service blueprints, financial models, burn-up charts, causal loop diagrams, and occasionally PowerPoint decks that appear to have been assembled during a hostage situation.
These are all models.
Some are explicit. Some are hidden. Some are good. Some are dangerously bad. But all of them simplify reality.
This is where philosophy becomes useful. A model is not the thing itself. It is a representation of the thing. It is an abstraction. It chooses what to include and what to ignore.
The Polish-American thinker Alfred Korzybski famously argued that:
“The map is not the territory.”
That is the point. A map is useful precisely because it is not the territory. A 1:1 scale map would be accurate, but useless. You would not unfold it in the car; you would simply be standing on another version of Britain, probably still stuck on the M62.
Blackadder Goes Forth made the same point rather more efficiently. In one scene, General Melchett proudly displays the ground recaptured during the offensive, only for Captain Darling to reveal that the map is drawn at a scale of one-to-one. The joke works because the map has become indistinguishable from the territory. It is perfectly accurate and almost completely useless, which is a fair description of quite a few corporate reporting packs.
The same is true of product models. A roadmap is not the product. A backlog is not the work. A Jira board is not reality, despite what some organisations appear to believe. These artefacts are representations, and the question is whether they help people think and act more effectively.
All Models Are Wrong, But Some Are Useful
The statistician George Box is often associated with the phrase:
“All models are wrong, but some are useful.”
That sentence should probably be printed above every product planning meeting, preferably in a font large enough to be visible from the back of the room where the finance director is quietly wondering why everything is late.
A model is always wrong because it leaves things out. It compresses reality into a smaller form. It removes detail. It simplifies behaviour. It assumes boundaries. It treats some things as stable even when they are not. It makes the world more legible than it really is.
But that does not make modelling pointless.
The purpose of a model is not to perfectly duplicate reality. If that were the aim, the best model of a product organisation would be the organisation itself, including every Slack message, unresolved dependency, awkward stakeholder conversation, half-written Jira ticket, and mysterious production issue nobody can reproduce.
That would not help.
A useful model does something different. It makes a hidden structure visible. It helps people reason. It gives teams a shared object to challenge. It allows decision-makers to ask better questions before the real system punishes them for bad assumptions.
What This Model Represents
The interactive model below is a simplified system dynamics model of a product delivery workflow.
Work enters the system, moves through a series of stages, and eventually exits as completed work.
The stages are:
- Discovery
- Analysis
- Development
- Testing
- Release
- Done
Each stage has a queue. Each transition has a flow rate. If work enters faster than the constrained stage can process it, the queue grows.
The model deliberately treats Testing as the initial constraint. That does not mean testing is always the bottleneck in real life. In another organisation, the constraint might be architecture, product discovery, customer sign-off, data migration, release governance, procurement, operational readiness, support capacity, or Dave, who is the only person who understands the billing integration and is somehow always on annual leave during month-end.
The point is not that Testing is always the problem.
The point is that every system has a constraint somewhere.
Interactive System Dynamics Model
Use the sliders to change the rate at which work moves through each stage.
The model shows three things at once:
-
The stock-and-flow diagram
This shows the structure of the system: queues, flows, source, sink, and the constraint. -
The queue readouts
These show how much work is waiting at each stage. -
The queue chart over time
This shows how queues accumulate as the simulation runs.
How to Read the Model
The boxes are stocks. A stock is an accumulation. In this model, each stock represents work waiting at a stage.
The arrows are flows. A flow is the rate at which work moves from one stock to another.
The sliders control the flow rates. For example, increasing the Development → Testing rate means development is pushing work into testing faster. Increasing Testing capacity means testing can process more work per tick.
This matters because systems are not improved by making every individual part faster. Systems improve when the constraint is identified, protected, and improved.
If Discovery, Analysis, and Development all move faster than Testing, the Testing queue grows. The organisation may feel busier. More work may appear to be progressing. Local metrics may even improve. But the total system has not improved because completed output is still governed by the constrained stage.
That is the key point.
The system does not care that one department has smashed its KPI. The system cares about flow.
Reality can be irritating like that.
Theory of Constraints: The Core Idea
The Theory of Constraints, developed by Eliyahu Goldratt, starts from a deceptively simple idea:
Every system has at least one constraint, and the constraint determines the performance of the whole system.
That sounds obvious until you look at how most organisations actually behave.
Instead of identifying the constraint, they often try to improve everything at once. They ask every team to go faster. They increase utilisation. They start more initiatives. They add more governance. They demand more reporting. They create more meetings to understand why the work is not moving, which is a bit like throwing more furniture into a blocked corridor to improve traffic flow.
The Theory of Constraints argues that improvement should be focused. Find the constraint. Exploit the constraint. Subordinate other work to the constraint. Elevate the constraint. Then look again, because the constraint may have moved.
This is deeply relevant to product management because product organisations are full of constrained systems.
The constraint might not be where the noise is loudest. The loudest part of the system is often just where the pressure is escaping.
Why Local Optimisation Can Make Things Worse
One of the most important lessons from the model is that local optimisation can damage global performance.
Imagine Testing is the constraint. The Testing queue is growing. Releases are delayed. Stakeholders are frustrated.
A common organisational response might be:
“Development needs to go faster.”
That sounds sensible, especially if you enjoy simple answers and have recently purchased an enterprise agile transformation framework.
But if Testing is already constrained, faster Development simply creates a bigger Testing queue. It increases work-in-progress without increasing completed output.
The organisation becomes busier, but not better.
This is one of the great traps of product delivery. Activity feels like progress because activity is visible. Flow is harder to see. Queues are often hidden. Waiting time gets normalised. Blocked work becomes background noise. Everyone is busy, yet value moves slowly.
In a constrained system, making the wrong part faster is like widening the road before a toll booth. You have not improved the journey. You have just created a more impressive traffic jam.
The Philosophy Bit: Abstraction, Reality, and Usefulness
There is a philosophical issue underneath all this: how do we know what is real enough to act on?
A model is a form of abstraction. It removes detail so that structure becomes visible. That means it is always incomplete. But incompleteness is not the same as uselessness.
Scientific models work this way all the time. Newtonian physics is not the final truth of the universe, but it is still useful if you want to build a bridge, fire a cannon, or understand why dropping a kettlebell on your foot is a poor recovery strategy. More precise theories exist, but Newton’s model remains useful within a certain domain.
Product models work the same way.
A simple delivery model will not capture every political, technical, commercial, and behavioural feature of an organisation. But it may still reveal a pattern that matters: work is entering the system faster than the constraint can process it.
The philosophical mistake is to demand perfect representation before accepting insight. That standard sounds rigorous, but it can become a way of avoiding uncomfortable conclusions.
A model does not need to be perfect to be decision-relevant.
The question is whether it is useful for the decision in front of you.
Mental Models and Product Judgement
Product managers use mental models constantly, whether they admit it or not.
A prioritisation framework is a model. A user journey is a model. A market segmentation is a model. A business case is a model. A quarterly roadmap is a model. A RAG status is a model, although sometimes a very theatrical one.
The danger is not using models. The danger is forgetting that they are models.
When a model becomes invisible, it becomes dangerous. People start treating the representation as reality. The Jira board says the work is nearly done, therefore the work is nearly done. The roadmap says Q3, therefore Q3 is real. The dashboard says green, therefore nothing important is on fire.
This is how organisations drift into nonsense while still appearing well-governed.
A good product manager keeps asking:
- What does this model include?
- What does it ignore?
- What assumptions does it make?
- What behaviour does it reveal?
- What behaviour might it hide?
- Is it useful for this decision?
That last question matters most.
What the Model Helps Us See
The model is useful because it makes several behaviours visible.
1. Queues are not random
Queues form when arrival rate exceeds processing capacity.
In real organisations this often appears as stress, delay, escalation, and firefighting. But underneath the noise, there is usually a structural explanation.
If work keeps arriving faster than the system can process it, queues will grow. No motivational speech, new dashboard, weekly steering group, or heroic programme manager changes that basic logic.
The queue is not being negative. It is just doing maths.
2. Throughput is governed by the constraint
The whole system can only move as fast as its limiting stage.
If Testing can process two items per tick, then the system cannot sustainably complete more than that, regardless of how fast Discovery, Analysis, or Development are moving.
That is uncomfortable because organisations often measure local activity rather than system throughput.
A team can be fully utilised and still be contributing to poor flow. In fact, full utilisation often makes flow worse because there is no slack to absorb variation, handle exceptions, or improve the system.
3. Local efficiency can damage global performance
Making one part of the system more efficient does not guarantee better overall performance.
If the improvement happens before the constraint, it may simply increase the amount of work waiting at the bottleneck.
This is why “keeping everyone busy” is not the same as improving delivery.
It is possible to optimise every department and still produce a badly performing system. This is one reason complex organisations can be so frustrating. Everyone can be doing their job correctly while the system as a whole behaves badly.
Very Kafka. Very product management.
4. The constraint can move
If you increase Testing capacity enough, the bottleneck may move elsewhere.
That is not failure. That is exactly what should happen. Once one constraint is improved, another part of the system becomes the limiting factor.
Continuous improvement is not about fixing everything at once. It is about finding the current constraint, improving it, then looking again.
This is why improvement is iterative rather than heroic. There is no final boss. There is just another constraint wearing a different hat.
Why This Matters for Product Management
Product managers often sit in the middle of constrained systems.
They are asked to increase delivery, respond to customers, support sales, manage stakeholders, reduce risk, improve quality, and make better roadmap decisions. The temptation is to treat the problem as a prioritisation issue:
“What should we do first?”
That is an important question, but it is not always the most important one.
A better systems question is:
“Where is the constraint, and are we making it better or worse?”
A roadmap is not just a list of features. It is demand entering a delivery system. Every item added to the roadmap creates downstream work: analysis, design, development, testing, release management, documentation, support, training, operational change, and sometimes contractual or commercial implications.
If the system is already constrained, adding more work does not necessarily increase output. It often increases queue depth.
This explains a common product management nightmare: the organisation agrees priorities, everyone works hard, progress is reported, and yet delivery still feels slow, brittle, and permanently behind.
That does not always mean people are failing.
Sometimes the system is behaving exactly as designed.
Unfortunately, the design is just bad.
The Product Manager as Systems Thinker
Good product management is not just backlog management. It is system stewardship.
That means understanding how demand enters the system, how work flows, where queues form, where decisions wait, where quality breaks down, and where organisational incentives accidentally encourage bad behaviour.
The Theory of Constraints gives product managers a way to move beyond surface-level delivery conversations.
Instead of asking:
“Why is this team not going faster?”
We can ask:
“What is currently constraining the flow of value?”
Instead of asking:
“How do we start more work?”
We can ask:
“What work should we stop starting?”
Instead of asking:
“How do we keep everyone utilised?”
We can ask:
“How do we improve flow through the system?”
These are better questions because they treat the product organisation as a system rather than a collection of busy individuals.
Product Questions the Model Encourages
For product managers, the value of this type of model is not the maths. It is the quality of the questions it creates.
Useful questions include:
- Where is work accumulating?
- Which queue is growing fastest?
- Which stage is setting the pace of the whole system?
- Are we increasing throughput or just increasing work-in-progress?
- Are we improving the constraint or feeding it faster?
- What work should we stop starting?
- What policy decision is creating unnecessary queueing?
- What would happen if we improved the actual constraint instead of the most visible pain point?
- Which metric is encouraging local optimisation at the expense of system performance?
- What assumption does our current roadmap make about available capacity?
These questions are more useful than simply asking whether everyone is busy.
Busy is easy.
Flow is harder.
The Dangerous Comfort of Detail
One reason organisations resist simple models is that simple models feel too simple.
Someone will always say:
“But it’s more complicated than that.”
They are usually right. It is more complicated than that.
But that does not automatically make the model wrong in a useful sense. It may mean the model is doing its job by making one important behaviour visible.
Complexity can become a hiding place. If every discussion ends with “it’s complicated”, nobody has to make a decision. Nobody has to identify the constraint. Nobody has to stop starting work. Nobody has to admit that the system is overloaded.
A useful model cuts through that.
It does not explain everything. It explains something important.
That is enough.
Final Thought
This model is not reality. It is a simplified representation of one important system behaviour.
But that is what models are for.
The point is not to build a perfect copy of the world. The point is to build something clear enough to improve judgement.
A useful model helps people see structure, challenge assumptions, and make better decisions.
The Theory of Constraints gives product managers a simple but powerful warning:
If you improve the wrong part of the system, you may not improve the system at all.
You may just create a bigger queue.
And if there is one thing every organisation already has enough of, it is a queue pretending to be a plan.